
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%

\documentclass[10pt, conference, compsocconf]{IEEEtran}
\usepackage{ifpdf}
\usepackage{multicol}
\usepackage{algorithmic}
\usepackage{subfloat}
\usepackage{algorithm}
\usepackage{textcomp}
\usepackage{listings}
\usepackage{graphicx}
\pagenumbering{roman}
\usepackage[table]{xcolor}
\usepackage[font=footnotesize]{subfig}

 
% Add the compsocconf option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Automatic Refactoring of Security-Policy-Based Software Systems for Performance Improvement and Architectural Model Preservation}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

\author{\IEEEauthorblockN{Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon}
\IEEEauthorblockA{Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon\\
line 2: University of Luxembourg\\
line 3: City, Country\\
line 4: Email:  \{donia.elkateb, tejeddine.mouelhi, yves.letraon\}@uni.lu}
\and
\IEEEauthorblockN{JeeHyun Hwang, Tao Xie}
\IEEEauthorblockA{Dept. of Computer Science, 
North Carolina State University, 
Raleigh, NC 27695, U.S.A\\\\
line 2: name of organization, acronyms acceptable\\
line 3: City, Country\\
line 4: Email: \{jhwang4@ncsu.edu,xie@csc.ncsu.edu\}}
}
\author{
Donia El Kateb, Tejeddine Mouelhi, Yves Le Traon\\

 \{donia.elkateb, tejeddine.mouelhi, yves.letraon\}@uni.lu\\\\
% For a paper whose authors are all at the same institution,
% omit the following lines up until the closing ``}''.
% Additional authors and addresses can be added with ``\and'',
% just like the second author.
JeeHyun Hwang, Tao Xie\\
Dept. of Computer Science, 
North Carolina State University, 
Raleigh, NC 27695, U.S.A\\
\{jhwang4@ncsu.edu,xie@csc.ncsu.edu\}\\
}
% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass
% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle
\pagestyle{plain} % No headers, just page numbers
\pagenumbering{arabic} % Roman numerals
\setcounter{page}{2}

\begin{abstract}
Modern access control architectures tend to separate the business logic from access control policy specification for the sake of authorizations 
manageability. Request evaluation is processed by a Policy Decision Point (PDP) that encapsulates the access control policy and interacts with the
 business logic through Policy Enforcement Points (PEPs). 
Such architecture may engender a performance bottleneck due to the number of rules that have to be evaluated by a single PDP.
To address the issue, we propose an automated refactoring approach to optimize the process of policy-based decision-making by splitting the
 single PDP into smaller decision points in synergy with the business logic. We conducted studies on XACML (eXtensible Access Control Markup Language), 
to identify the best PDP splitting configuration. Our evaluation results show that our approach reduces the request evaluation time by up to 9 times
 and preserves the architectural model.

\end{abstract}

\begin{IEEEkeywords}
Security policy, performances, access control, architecture, XACML, Optimization...

\end{IEEEkeywords}


% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
%- Access control security vs compromise performance
%- Define acces control in xacml setting (subject action resource)
%- Situation of our approach Context evaluations previous approach + contribution dimensions
%- Main idea + open reserach issues
%-Structure
Should we sacrifice performance when considering some security requirements like implementing access control measures? 
IT experts would answer ``Absolutely not, in today's competitive market, this would impact the business''. However, what happens 
in the real access control management systems, is that organizations with divisionalised structures and workflow, several datatypes and heteregenous 
ressources have an exponential growth of their access control policies. Such combinatorial explosion of the access rights to be computed at 
runtime may degrade dramatically the decision making time of the PDP, leading to performance bottlenecks and impacting service availability.

%which may reflect a complex structure of an organization, with its  structure and its
%assets variety, this can lead to deal with access control policies intricate in design, 

 Few companies would agree paying the price for improving 
their security if it degrades performances in such a way it impacts users satisfaction. As highligted by \cite{Xengine} and \cite{Xengine1}, this performance
 problem is crucial for the adoption of access control security policies in real world information systems deployment: such solution must both comply with certain access control architectural requirements like 
scalability, transparence and remain performant.\\


Current access control architectures rely on a key concept which is the separation of the policy enforcement point (PEP), which
 is located inside the application (business logic of the system) and is in charge of regulating and enforcing the policy, and the policy
 decision point (PDP) which encapsulates the policy, receiving requests from the PEP and responding to these requests, either by granting 
or denying access. The policy is therefore centralized in one point, the PDP. Centralization of the PDP offers some advantages since the access 
rights are easier to manage and maintain when embedded in  a single component. This centralization is also a pitfall for performances since the 
PDP must both manage the load of parallel user request sessions as well as the computation time for each request sent by PEPs.

This paper deals with performance issues for policy-based software systems, the proposed approach combines the advantages of the request evaluation
time and enables us to preserve invariant the synergy property in our access control model. We define this property as the cardinality based feature that 
characterizes the association between the PEPs and PDP in the access control model. We assume that this property holds if there is an injective association 
between the PEPs and the PDPs that maps each PEP to a single PDP. We claim that maintaining this property will enable the system stakeholders (architects, administrators, security experts)
 to still have a transparent and scalable solution for maintaining access control architecture and managing access control policies. 

In this work, we consider policy-based software systems implemented in XACML, a commonly used extensible access control markup language, 
for defining authorization rules. An authorization rule specifies if, and in which circumstances, subjects can perform given actions on resources. 
XACML has emerged as a pressing need for a common language for expressing access control security policies, to manage the enforcement of all 
the elements of its organizational security policy in all information system components.


The approach is automated for optimizing the process of decision
 making in XACML request evaluation. 
It combines two facets: (1) performance optimization criteria to split the PDP into smaller decision points,
 (2) architectural model invariant preservation to keep the synergy between PDP and PEPs.
The performance optimization facet of the approach lies in distributing the centralized PDP into smaller, more performant ones,
 through an automated refactoring of the global access control policy, that involves grouping the rules that have to be evaluated for
 each incoming request into relevant, consistent subsets. 
Technically, we have defined a set of splitting criteria to decompose the global policy into smaller policies. A splitting 
criterion selects and groups the access rules of the overall PDP into specific PDPs. A splitting criterion thus represents 
a specified combination of target elements: the rules that have the same specified target elements constitute a sub-policy. 

The approach is supported by a prototype tool (XACML Splitter) that takes as input a splitting criterion and an XACML global 
policy and returns a set of different sub-policies. This first facet leads to a comparison of the performances of the proposed
 splitting criteria for our different case studies. 

The architectural model preservation facet aims at selecting the splitting criteria that do not alter the initial architectural
 model and keeping invariant the synergy property of our access control model. The proposed technique keeps the separation of the PDP and 
the 
PEP and focuses on establishing an appropriate mapping 
between them. We claim that the best splitting criteria must thus both improve performances and satisfy our architectural invariant: the 
injective 
relationship must be maintained, linking each PEP to a given distributed PDP. In such a configuration, each PEP in our system 
can be mapped to a set of rules that will be relevant when evaluating the 
request. Being automated, the approach is transparent for the security expert and the evaluations show that it enables to have a decision making process 
which is 9 times faster than a scenario that considers the global access control policy and preserves the architectural model.

The remainder of this paper is organized as follows: section 2 introduces XACML, section 3 proposes our adopted strategy, 
section 4 presents experimental data to show the consistency of our claims and discusses the effectiveness of our technique. 
Finally, section 5 presents an overview of the related work before concluding in section 6 with some suggestions for future research 
directions.

\section{Context/Problem Statement}
In this section, we start by describing the access control scenario in XACML data flow model, further, we present the performance 
issues in XACML data flow model and the synergy feature that we aim to keep invariant in our automated process of performance tuning.

\subsection{Access Control Data Flow Model}

Most access control scenarios involve an access control policy which is modeled, analyzed and implemented as a separate component encapsulated in a PDP,
 which interacts with the business logic through the PEP that may receive access control requests. 
Like illustrated in Figure \ref{pep-pdp}, the PEP in turn calls the PDP to retrieve an authorization decision based on which it will grant or deny access. The authorization decision is made 
through the evaluation of the different rules in the access control policy, subsequently, authorization decision is returned to the PEP.

This separation in current access control systems simplifies policy management across many heteregenous systems and enables to avoid potential
 risks that can arise from incorrect policy implementation, when scattered throughout the application.


In this paper, we focus on access control decision making for XACML based authorization policies.
 XACML \cite{site} is an OASIS open standard based 
on XML language for access control. It defines a syntax for policies language and request/response language.


\begin{figure}[!h]
\begin{center}
\includegraphics[width=10cm, height=7cm]{business-logic.pdf}
\caption{Access Control Request Processing}
\label{pep-pdp}
\end{center}
\end{figure}
\subsection{XACML Access Control Policies and Performance Issues}
%\begin{figure}[!h]
%\begin{center}
%\includegraphics[width=12cm, height=10cm]{optimisation.jpeg}
%\caption{\label{XACML Architecture}XACML Architecture}
%\end{center}
%\end{figure}
In XACML paradigm, a policy set is defined as a sequence of policies, a combining algorithm and
 a target. A single access control policy is expressed through a target, a set of rules and a rule combining algorithm. 
The target defines a set of resources, subjects, and actions to which a rule is intended to apply. A rule set is a sequence of rules. Each rule is composed of a 
target, a condition, and an effect. The condition is a boolean expression that specifies the different restrictions on the elements in the target, 
the effect is either one of permit, deny, or indeterminate. 
Each algorithm represents a different method of combining multiple decisions into a single decision, and thus is used to deduce the final decision, 
in case of potential conflicting decisions that can result from sub-policies evaluation. For example, the Permit 
Override algorithm allows the policy to evaluate to permit if any rule in the policy evaluates to permit, to deny if all the rules evaluate to deny, 
to non applicable if no rule is applicable. Figure \ref{figur1} shows a simple XACML policy that denies
the subject Bob to borrow a book.

 

\fontsize{5}{5}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm, height=7cm]{xacml.pdf}
\caption{XACML Policy Example}
\label{figur1}
\end{center}
\end{figure}

The XACML request encapsulates attributes that define who is making the request, what protected resource in $S$ is being requested and
 what operation or action is to be performed on that resource. A request which satisfies both the rule target and the rule condition has a response 
that is sent with the decision specified by the effect element in the
 applicable rule. If a request does not satisfy both the target and the condition, the response yields ``NotApplicable''.
\\As standard, XACML enables administrators to externalize access control policies for the sake of interoperability since access control policies
 can be designed 
for any underlying programming language and for any supporting platform, its flexibility permits to meet access control policies requirements so
 that new requirements
 are supported. 
%\centering
%\figure[DREF metamodel\label{fig:drefMM}]
%        {\includegraphics[width=0.5\textwidth]{figure/drefMM}}
%\figure[SETER Process: Security Testing for Resilient Systems 
%\label{fig:seter}] {\includegraphics[width=0.49\textwidth]{figure/seter}}
%\caption{DREF and SETER: Conceptual and Operational Frameworks for evaluating resilient systems}
%\end{figure*}
However the increasing complexity of organizations in term of structure, relationships, activities and access control requirements has impacted 
access control polices design and led to deal with access control policies where the number of rules, that depicts the associations between resources, 
entities and actions in a given access control policy, is huge.

This observation should raise performance concerns related to request evaluation time for XACML access control policies since 
a performance bottleneck can lead to degrade the whole system efficiency and this may slow down the overall business processes. Considering XACML 
request evaluation, many factors may lead to reduce XACML requests evaluation performance especially in the case where a PDP has 
to manage multiple access control requests. Due to space limitations, we only mention the following factors:

\begin{itemize}
 \item An XACML policy may contain several attributes that constitute a descriptive information about the target elements, the retrieval of
 varying size of attributes values for each request within XML elements in a request evaluation process may engender a performance bottleneck.
\item A policy can also contain multiple sub-policies, the effect of the whole
policy is determined by combining the effects of the sub-policies according to a combining algorithm, the computation of resulting effect from 
sub-polices is also considered as a potential evaluation time latency.
\item Conditions evaluation in XACML rules may slow the decision making process since these conditions can be so complex because they can 
be built from an arbitary nesting of non-boolean functions and attributes. 
\end{itemize}

\subsection{Preserving our Access Control Architectural Model}
Managing access control policies is one of the most challenging issues faced by organizations. 
Frequent changes in access control systems may be required to meet business needs. An access control system has to handle some specific 
requirements like role swap when employees are given temporary assignments, changes in the global access control policies and procedures, 
new assets, users and job positions in the organization, etc...

All these facts make access control architectures very difficult to manage, and plead in favor of a 
simple access control architecture that can handle easily all evolvable facets of evolution in access control systems. 
In the line of reasoning about performance, we propose to maintain the simplicity of the access control architecture whose entity diagram 
is presented in Figure \ref{model}.

In this architecture, a set of business processes, that comply to users needs, are encapsulated in a given business logic which is enforced 
by multiple PEPs. Conceptually, the decision is decoupled from the enforcement and involves a decision making process in which each PEP interacts 
with a single PDP, thus a single XACML policy is evaluated to provide the suitable response for an access control request provided by a PEP. 

We claim that considering a single XACML policy file for each initiating PEP enables to ease policies and rules management and to maintain 
a simple architecture in which the suitable decision point is triggered by a PEP in a given request.

For this sake, we propose to keep invariant the cardinality based feature between the PEP and the PDP in our system, which we defined as 
the PEP-PDP synergy, thus a PEP triggers a single PDP that manages a single policy file. We assume that adopting a strategy to increase request evaluation performance should keep invariant this property 
which holds already for the initial architecture. The next section will describe our approach and will give an insight of the process supporting it.


\begin{figure}[!h]
\begin{center}
\includegraphics[width=8cm, height=2cm]{model.pdf}
\caption{Entity Diagram of our Access Control Model}
\label{model}
\end{center}
\end{figure}

\section{Our Approach to Optimizing Decision Making in XACML} 
We consider the decision making process in XACML, and we propose an approach that aims at providing a certain performance improvement by refactoring 
the global access control policy. Since a decision making process, involves the evaluation of all the rules in the global policy, we propose to reduce 
the number of rules that have to be evaluated in the global XACML policy. The intuition behind this (which will be backed by our experimental 
results) is quite intuitive. It boils down to the idea that the policy evaluation is faster when there are few rules to be processed and checked to get
 the decision. Obviously, a PDP that has to check 2 rules will be much faster that a PDP checking 200 rules. However what happens in a request evaluation 
process is that for a given access control request, some rules are evaluated in the global policy whereas some of those rules are not applicable to 
the request. Starting from this observation, we propose a scenario in which only the relevant rules for a given request will be evaluated in the decision
 making process, this scenario is based on a refactoring operation supported by our implemented prototyping tool that automates the policy splitting 
into ``smaller''' policies based on target elements combination. In the following, we will provide all technical details to illustrate our refactoring 
process, and show how can we select the splitting criterion that enables to preserve our model invariant.
%a tradeoff between performance and access control policies management requirements like transparency and scalability.

\subsection{XACML Policy Refactoring Process}
%In \cite{clustering}, the authors decompose the global policy into a set of policies where each set gathers the subjects that share common applicable
%rules whereas in \cite{decomposition} the proposed approach involves evaluating all the boolean expressions \cite{boolean} for all the rules in the 
%policy and clustering all the rules having the same boolean expression.
%the PDP component which fetches the necessary policies and necessary attributes for decision making.

Our conceptual approach to improve the performance in the XACML decision making process focuses exclusively on reducing the time spent on PDP activity.
We assume that this time would be reduced considerably if the PDP handles a ``smaller'' policy. We propose to transform P into smaller policies 
P$_{SC_{w}}$ where each policy conforms to what we define as a Splitting Criteria SC$_{w}$.
A splitting criteria SC$_{w}$ defines the set of target elements, that can be considered to classify all the rules into sets of rules having the 
same target elements, w is a weight that denotes the number of target elements that have to be considered conjointly for aggregating rules into
 an unified set based on specific target elements selection.

An XACML policy P can be refactored considering one target element, in such setting a policy can be splitted into a set of policies where the different 
rules have the same subject, resource or action. Rules can also be aggregated considering two splitting criteria like $<$Subject, Action$>$ or
 $<$Action, Resource$>$, in this setting, a global policy will be transformed into set of policies where rules in the same sub-policy have the same 
couple of target elements. 
We can go further in our grouping strategy by creating sub-policies whose 
rules match a specific triplet of resource, action and subject. Table 1 shows all the combination of the splitting criteria according to the weight of 
target elements.

\begin{table}[h!]
\centering
\begin{tabular}{|l|c|}   
\hline  \rowcolor{black} 
\scriptsize \bf
\textcolor  {white}{Splitting Criteria}&\scriptsize \bf \textcolor{white}{Elements}\\ \hline
\scriptsize 
$SC_{1}$&\scriptsize {$<Subject>, <Resource>, <Action>$}\\ \hline
\scriptsize 
$SC_{2}$&\scriptsize  {$<Subject,Action>, <Subject,Resource>$}\\&\scriptsize{$<Resource,Action>$}\\  \hline
\scriptsize  
$SC_{3}$&\scriptsize  {$<Subject,Resource,Action>$}\\ \hline
\end{tabular}
\caption{Splitting Criteria}\label{table1}\end{table}
In this setting, we put forward an access control architecture built with multi policy decisions points (PDPs), where each PDP enforces
a policy that complies to a certain splitting criterion, we denote the resulting policies by P$_{SC_{w}}$. A mapping table is used to define the 
mapping between potential request target elements and corresponding sub-policies P$_{SC_{w}}$.
We propose a schema in which a given PEP interacts with a dispatcher that receives the PEP's request, fetches the mapping table and extracts 
the suitable PDP that has to provide a response for given request. Figure \ref{decomposition}.a gives an overview of this architecture in the 
case where SC$_{1}$=$<$subject$>$ is chosen as a splitting criterion. In this scenario, the PEP formulates the request, and forwards it to an intermediary component ``The dispatcher'', that receives the XACML request and fetches 
the subject's request attributes. The correspondings PDPs that are relevant for the subjects attributes are localized through the mapping table, and used to provide the 
XACML response to the initiating PEP. 

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm, height=12cm]{pep-pdp.pdf}
\caption{Request processing: (a)-PDP decomposition based on target elements: SC$_{1}$=$<$subject$>$/(b)-
PDP decomposition based on system functions}
\label{decomposition}
\end{center}
\end{figure}
%With the objective of highlighting some relevant considerations that have to be taken in the decomposition process:
\begin{large}
\end{large}

In the following, we explore the prospects of our refactoring process through some technical examples that take into 
consideration XACML language features:
\begin{itemize}
\item The XACML policy number 1 presented in \ref{xacml-decomposition} is a simple XACML policy whose target elements
 defined for the global XACML policy are applicable to any subjects, resources and actions elements: 
$<$AnyResource$>$, $<$AnySubject$>$, $<$AnyAction$>$. The refactoring of this policy according to the splitting criteria 
SC$_{1}=<$Subject$>$ consists in splitting the XACML policy into sub-policies 2 \& 3 where each sub-policy groups the rules 
that are relevant for each subject. XACML polices 2 and 3 are the two resulting policies that present how the present 
rules for Bob and Alice in the policy 1 are dispatched in policies 2 and 3.

\item XACML attributes, enable to give some information to describe target elements, our refactoring process
does not affect multi-attributes target elements. The subject element shown in Figure \ref{multi-attributes} 
defines a subject and subject-related entities described through two attributes 
(one is "role" and the other is "isEq-subjUserId-resUserId"). This subject can match with a request if the request has
 at least the role pc-member and if isEq-subjUserId-resUserId
 is true. In the case the splitting criteria is $SC_{1}=<Subject>$ is given in a refactoring process, this subject element 
will not be impacted by our refactoring process as its attributes have to be evlauated conjointly in a decision making process.

\item We have shown in Figure \ref{xacml-decomposition}, how a policy is refactored in case it has an empty 
target. In the case, where the policy target is not empty, we proceed by recursive refactoring, we split the 
policies according to target elements mentionned in the policy target and then we split the policies according 
to target elements in the rules. Figure \ref{xacml-decomposition1} is an example that illustrates this process.

\end{itemize}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=8cm, height=3.5cm]{xacml-match.pdf}
\caption{Multi-attributes target element}
\label{multi-attributes}
\end{center}
\end{figure}
\begin{figure}[!h]
\centering
\includegraphics[width=9cm, height=10cm]{exemple1.pdf}
\caption{XACML policy refactoring process}
\label{xacml-decomposition}
\end{figure}

\begin{figure}[!h]
\begin{center}
\includegraphics[width=7cm, height=7cm]{xacml-match1.pdf}
\caption{Policy refactoring in case the target elements are not empty}
\label{xacml-decomposition1}
\end{center}
\end{figure}

\subsection{Architecture Model Preservation: PEP-PDP Synergy}
We consider the different splitting criteria that we have identified in the previous section and we propose to select the splitting criteria that 
enables to preserve our architecture invariant, in the sense that it enables to map a single PDP to each PEP.
A PEP-PDP mapping is observable through the code at application level, in fact, a deep analysis of the PEPs and 
the corresponding triggered rules enables to explicitly describe this mapping. On the application level, every PEP is mapped to a service
 implementation through a system method call that triggers a decision making process by activating some specific rules in a single PDP.
The algorithm 1 is taken from \cite{legacy}, this portion of the code shows an example of a PEP which is implemented by the method checkSecurity 
which calls the class SecurityPolicyService that initiates the PDP component.
\begin{algorithmic}
\begin{algorithm}[!h]
\caption{System security function that describes a PEP enforcement}
   \STATE public void borrowBook(User user, Book book)
   \STATE throws SecuritPolicyViolationException {
   \STATE   // call to the security service
\STATE \hspace{0.5cm} \textbf{ServiceUtils.checkSecurity(user,
\STATE LibrarySecurityModel.BORROWBOOK\_METHOD,
\STATE LibrarySecurityModel.BOOK\_VIEW);}
\STATE ContextManager.getTemporalContext());
    \STATE  // call to business objects
    \STATE  // borrow the book for the user
\STATE \hspace{0.5cm} book.execute(Book.BORROW, user);
\STATE      // call the dao class to update the DB
\STATE \hspace{0.5cm} bookDAO.insertBorrow(userDTO, bookDTO);}
\end{algorithm}
\end{algorithmic}

An analysis of this code reflects that this function will trigger exclusively all the rules organized by the couple (Action, Resource) for 
the subject given as input parameter.

%%%%%
Conceptually, we propose to transform the global policy into subsets of rules where each subset can be mapped to a PEP.
In this setting, each single request initiated by a specific PEP, will have its corresponding evaluating PDP conforming to the PEP-PDP matching. 
This implies that the different method calls initiated by PEPs are identified at the code level at the decision making time and mapped to their 
corresponding PDPs. A mapping table is used to establish the link between each PEP implementation and the corresponding rules 
encapsulated in a given PDP. A general schema for this approach is presented in Figure \ref{decomposition}.b.

This structure enables to preserve the synergy property illustrated in Figure \ref{synergy}, in our access control system, since a given request evaluation 
triggered by a single PEP will be handled by a single PDP and thus a request evalution process, operationally, will involve 
a single XACML policy file. 

\begin{figure}[!h]
\begin{center}
\includegraphics[width=7cm, height=2.5cm]{synergy.pdf}
\caption{Synergic system / Non synergic system}
\label{synergy}
\end{center}
\end{figure}

Depending on the system architecture, establishing this mapping may require to identify all the enforcements points in an application, and to 
track the different method calls 
engendered from these specific enforcement calls to map them to the relevant access control rules. This task seems not to be an easy to perform, 
since it is 
dependant on the underlying platform. 

In this work, we do not perform code analysis to identify these calls as we know in advance, our different PEPs and their corresponding relevant rules. 
We propose to identify automatically the different PEPs in a future work, however for this work, we can identify easily the different PEPs as we know in
 advance that system functions are implemented through the consideration of (Resource, Action) target elements thus a policy refactoring according 
to system function is assimilated to policy refactoring according to the splitting criteria SC$_{1}=<$Action,Resource$>$. 

Our experiments have consistantly shown that adopting a policy refactoring based on system functions enables to improve the decision making process
 performance taking into consideration how the PEP interacts with the PDP and how the rules are activated across the system, and preserves 
the architecture invariant since we keep unchanged the cardinality relation between PEP and PDP.
 
As depicted in Figure \ref{overallprocess}, the refactoring process is automated and starts by specifying and creating the XACML file which 
will be split by our tool according to a specified SC that can be chosen by an access control skateholder. Afterwards, the policies are included in the 
framework that supports our approach. For every change in the access control policy, the initial policy is updated and 
split again in order to be included again in the framework.

\begin{figure}[!h]
\includegraphics[width=8.5cm, height=8cm]{Overall-process.pdf}
\begin{center}
\caption{Overview of the process of defining and deploying XACML policies}
\label{overallprocess}
\end{center}
\end{figure} 
From a point of view of the system administration, maintaining and updating the access control policies is completely a standalone and simple process.
 The input is usually a high-level representation of access control (RBAC, OrBAC), which is derived into a centralized XACML file.
 This input remains the same than before the access control 
performance issue is tackled.
Our process is transparent in the sense that it does not impact the existing functional aspects of the control access management system, 
for system administrators who have to adapt the system security policy over time and have to manage various dimensions of access control 
systems (scalability, maintainability, evolvability).
\section{Experimental results}
We propose to prove the legitimacy of our proposal by experimental results. In our evaluation, we use a machine (dual Core, Ubuntu 10) blablablabla 
(environment).
%and we anticipate a future work to automate our approach.
%\begin{figure}
 % \centering
  %\subfloat[A gull]{\label{fig:gull}\includegraphics[width=0.3\textwidth]{gull}}                
  %\subfloat[A tiger]{\label{fig:tiger}\includegraphics[width=0.3\textwidth]{tiger}}
  %\subfloat[A mouse]{\label{fig:mouse}\includegraphics[width=0.3\textwidth]{mouse}}
  %\caption{Here we a gull \ref{fig:gull} and a tiger \ref{fig:tiger} and a mouse \ref{fig:mouse}}
  %\label{fig:animals}
%\end{figure}
\subsection{Experimental Results: policy refactoring through target elements combination}
In this section we present the evaluation results of applying policy refactoring based on target elements combination.
The different experiments were carried-out using the following XACML studies presented in \cite{testcase}:
\begin{itemize}	
\item LMS: The library management system offers services to manage books in a public library.
\item VMS: The virtual meeting system offers simplified web conference services. The virtual meeting server allows the organization of work meetings on a distributed
platform.
\item ASMS (Auction Sale Management System): allows users to buy or sell items online. A seller can start an auction by submitting a description of the
item he wants to sell and a minimum price (with a start date and an ending date for the auction). Then usual bidding process can apply and people can bid on this
auction. One of the specificities of this system is that a buyer must have enough money in his account before bidding.
\end{itemize}.


\begin{figure*}
  \centering
  \subfloat[LMS]{\label{fig:gull}\includegraphics[width=0.36\textwidth]{LMS.pdf}}                
  \subfloat[VMS]{\label{fig:VMS}\includegraphics[width=0.36\textwidth]{VMS.pdf}}
  \subfloat[ASMS]{\label{fig:ASMS}\includegraphics[width=0.36\textwidth]{ASMS.pdf}}
  \caption{Processing Time for our 3 systems LMS, VMS and ASMS}
  \label{fig:processing time}
\end{figure*}


\begin{figure}[!h]
  \centering
\includegraphics[width=8cm, height=8cm]{pdpnumber.pdf}
\begin{center}
\caption{Overview of the process of defining and deploying XACML policies}
\label{overallprocess}
\end{center}
\end{figure} 


To conduct our evaluation, we have implemented a tool that takes a splitting criteria and an XACML policy as entry parameters and provides sub-policies
that gather the set of XACML rules that conforms to a splitting criterion provided as input parameter. 
Our policy Splitter Tool, splits the global policy into small policies according to different SC. We conducted 10 executions to measure the evaluation time besides the execution time 
for an access control request from building its attributes to getting the response for the global access control policy and refactored policies. In the following, we present the average
 time for both the evaluation time and the overall execution time for the different case studies.
Like shown in Figure \ref{fig:processing time} which illustrates the evaluation time for the different case studies, we can observe that the splitting criteria SC=$<$Action, Resource$>$
enables to have the lowest evaluation time.

\subsubsection{Experimental Results using policy decomposition and Xengine}
In this part, we run refactored policie with Xengine, we measured measured processing time (ms) for randomly generated 1,000 requests. 
For $SC_{1}=<Subject>$, $SC_{2}=<Subject, Action,>$, $SC_{3}=<Subject, Action, Resource>$ CC3, I choose (SAR). 
For XEngine, I choose global policy evaluation and evaluation for decomposed policies with regards to $SC_{2}=<Subject, Action,>$.
\begin{table*}
\centering
\begin{tabular}{|l|l|l|l|l|l|l|}   
\hline  \rowcolor{black} \scriptsize \bf \textcolor {white}{Case Study}
& \scriptsize \bf \textcolor {white}{Global Policy}
& \scriptsize \bf \textcolor  {white}{CC1 (S)}
& \scriptsize \bf \textcolor  {white}{CC2 (SA)}
& \scriptsize \bf \textcolor  {white}{CC3 (SAR)}
& \scriptsize \bf \textcolor {white}{XEngine - Global}
& \scriptsize \bf \textcolor  {white}{XEngine – CC2 (SA)} \\ \hline
\scriptsize  {LMS}
& \scriptsize {328}
& \scriptsize {297}
& \scriptsize {171}
& \scriptsize {47}
& \scriptsize {79}
& \scriptsize {31}
  \\ \hline
\scriptsize  {VMS}
& \scriptsize {579}
& \scriptsize {110}
& \scriptsize {16}
& \scriptsize {16}
& \scriptsize {31}
& \scriptsize {16}
  \\ \hline

\scriptsize  {ASMS}
& \scriptsize {640}
& \scriptsize {125}
& \scriptsize {0}
& \scriptsize {281}
& \scriptsize {31}
& \scriptsize {16}
 \\ \hline



\scriptsize  {Examples provided by NCSU}
& \scriptsize {640}
& \scriptsize {125}
& \scriptsize {0}
& \scriptsize {281}
& \scriptsize {31}
& \scriptsize {16}
 \\ \hline

\end{tabular}
\caption{evaluation time for all the case studies}\end{table*}


\section{Related work}
This work brings new dimensions to our previous work on XACML by presenting a new approach to optimize request evaluation process 
that takes into consideration our access control architectural model. 
Our previous work \cite{Xengine} and \cite{Xengine1}, presents an alternative solution 
to brute force seraching based on an XACML policy conversion to a tree structure to minimize the request evaluation time. 
We started by the numericalization and normalization of the different rules in a given policy. In the numericalization phase, 
all string values are converted into integers. During normalization phase, the hierarchical structure of a policy is normalized
 into a flat structure. The resulting policy is transformed into a decision diagram which is converted into $k$ tables called 
forwarding tables. The decision (request-policy match) search is done through the traversal of the different $k$ tables.\\

The present work tackles the performance problems in XACML decision making and proposes a technique for policy refactoring 
which can be used conjointly with XEngine, the novelty of our approach lies in taking into consideration our model invariant in 
the optimization process. 

Some other work have provided contribution in the same direction, in \cite{decomposition}, 
the authors decomposed the global XACML policy into local policies releated to collaborating parties, the local policies 
are sent to corresponding PDPs. The request evaluation is based on local policies by considering the relationships among local
 policies. In their approach, the request evaluation optimisation is based on storing the effect of each rule and each local policy for 
a given request. The decision caching is then used to optimise evaluation time for an incoming request, however the authors have 
not provided experimental results to measure the efficiency of their approach. 

In \cite{clustering}, the authors proposed two approaches that could be coupled together to enhance evaluation time in XACML.
Their first contribution consists in reordering policies and rules within a policy set so that evaluation is limited only to 
policies and rules that are most likely to provide a significant match. The second contribution improves the rule reordering, it consists in categorizing
 policies using aggregation of subjects like in  \cite{decomposition} and hence improving PDP performance.

While the previous approaches have focused on the PDP engine to optimise the request evaluation, The authors in 
\cite{XACMLstructure}, addressed this problem by acting on the representation of the XACML policy itself. They rely 
on XACML flexibility to describe the access rules with different policy 
configurations. A cost analysis, which is attached to each configuration, enables to select the optimised configuration.
The authors in \cite{comparaison}, presented an empirical study of XACML PDP implementation performance. They take into 
consideration two criteria: the cost to load a policy from disk to memory and the cost to evaluate a given request against
 available policies.



\section{Conclusion and Future Work}
In this present work, we have provided experimental results that argue in favor of our approach and we have anticipated 
a future work to localize automatically the PEPs in a given application.
The originality of our approach lies in keeping the link invariant between the PEP and the PDP in XACML access control system 
while considering the optimization issues in XACML architecture.

What makes it really challenging is that it opens a new reserach issues. Among these issues we can cite two relevant ones: How 
can we identify dynamically the different system functions in our system independently of the underlying platform and language? 
How can we establish dynamically a link between a system function and a set of rules?




% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.




% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{1}

\bibitem{IEEEhowto:kopka}
H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
\bibitem{comparaison}
Turkmen, Fatih and Crispo, Bruno,
Performance evaluation of XACML PDP implementations,
Proceedings of the 2008 ACM workshop on Secure web services,
SWS '08,
2008,
978-1-60558-292-4,
Alexandria, Virginia, USA,
37--44,
8.\\

\bibitem{XACMLstructure}
Miseldine, Philip L.,
Automated xacml policy reconfiguration for evaluation optimisation,
Proceedings of the fourth international workshop on Software engineering for secure systems,
SESS '08,
2008,
978-1-60558-042-5,
Leipzig, Germany,
1--8.\\

\bibitem{clustering}
Marouf, Said and Shehab, Mohamed and Squicciarini, Anna and Sundareswaran, Smitha,
Statistics \& clustering based framework for efficient XACML policy evaluation,
IEEE Press,
Proceedings of the 10th IEEE international conference on Policies for distributed systems and networks,
http://portal.acm.org/citation.cfm?id=1812664.1812693.\\

\bibitem{Xengine1}
Alex X. Liu and Fei Chen and JeeHyun Hwang and Tao Xie,
Designing Fast and Scalable XACML Policy Evaluation Engines,
IEEE Transactions on Computers,
99,
PrePrints,
0018-9340,
http://doi.ieeecomputersociety.org/10.1109/TC.2010.274,
2010,
IEEE Computer Society.\\

\bibitem{Xengine}
Alex X. Liu and Fei Chen and JeeHyun Hwang and Tao Xie,
Xengine: a fast and scalable XACML policy evaluation engine,
SIGMETRICS,
2008,
265-276,
http://doi.acm.org/10.1145/1375457.1375488.\\



\bibitem{decomposition}
Lin, Dan and Rao, Prathima and Bertino, Elisa and Li, Ninghui and Lobo, Jorge,
Policy decomposition for collaborative access control,
Proceedings of the 13th ACM symposium on Access control models and technologies,
SACMAT '08,
2008,
978-1-60558-129-3,
Estes Park, CO, USA,
103--112,
http://doi.acm.org/10.1145/1377836.1377853,
ACM.\\



\bibitem{xacmltesting}
Tejeddine Mouelhi and
Yves Le Traon and
Benoit Baudry,
Transforming and Selecting Functional Test Cases for Security
Policy Testing,
ICST,
2009,
171-180,
http://doi.ieeecomputersociety.org/10.1109/ICST.2009.49,
DBLP:conf/icst/2009,
DBLP, http://dblp.uni-trier.de.\\


\bibitem{boolean}
Lin, Dan and Rao, Prathima and Bertino, Elisa and Li, Ninghui and Lobo, Jorge,
Policy decomposition for collaborative access control,
Proceedings of the 13th ACM symposium on Access control models and technologies,
SACMAT '08,
2008,
978-1-60558-129-3,
Estes Park, CO, USA,
103--112,
10,
ACM,
New York, NY, USA.\\

\bibitem{site}
http://sourceforge.net/projects/sunxacml/\\
\bibitem{testcase}
Tejeddine Mouelhi and Yves Le Traon and Benoit Baudry,
Transforming and Selecting Functional Test Cases for Security Policy Testing,
ICST,
2009,
171-180,
http://doi.ieeecomputersociety.org/10.1109/ICST.2009.49.\\
\bibitem{formal}
Gail-Joon Ahn and Hongxin Hu and Joohyung Lee and Yunsong Meng,
Representing and Reasoning about Web Access Control Policies,
COMPSAC,
2010,
137-146,
http://dx.doi.org/10.1109/COMPSAC.2010.20.\\

\bibitem{legacy}
Traon, Yves Le and Mouelhi, Tejeddine and Pretschner, Alexander and Baudry, Benoit,
Test-Driven Assessment of Access Control in Legacy Applications,
Proceedings of the 2008 International Conference on Software Testing, Verification, and Validation,
2008,
978-0-7695-3127-4,
238--247,
10,
http://portal.acm.org/citation.cfm?id=1381305.1382087,
10.1109/ICST.2008.60,
1382087,
IEEE Computer Society,
Washington, DC, USA,
\\
\end{thebibliography}

% that's all folks
\end{document}


